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Abstract 


This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that 
were reported and that have proven to cause interoperability issues when RFC 7030 was 
extended. 


This document deprecates the specification of "Content-Transfer-Encoding" headers for 
Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors 
in ASN.1 that were present. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8951. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 


Richardson, et al. Standards Track Page 1 


RFC 8951 Clarification of EST November 2020 


with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


Enrollment over Secure Transport (EST) is defined in [RFC7030]. The EST specification defines a 
number of HTTP endpoints for certificate enrollment and management. The details of the 
transaction were defined in terms of MIME headers, as defined in [RFC2045], rather than in 
terms of the HTTP protocol, as defined in [RFC7230] and [RFC7231]. 


[RFC2616] and later Appendix A.5 of [RFC7231] have text specifically deprecating Content- 
Transfer-Encoding. However, [RFC7030] incorrectly uses this header. 


Any updates to [RFC7030] to bring it in line with HTTP processing risk changing the on-wire 
protocol in a way that is not backwards compatible. However, reports from implementers 
suggest that many implementations do not send the Content-Transfer-Encoding, and many of 
them ignore it. The consequence is that simply deprecating the header would remain compatible 
with current implementations. 


[BRSKI] extends [RFC7030], adding new functionality. Interop testing of the protocol has revealed 
that unusual processing called out in [RFC7030] causes confusion. 


EST is currently specified as part of [IEC62351] and is widely used in government, utilities, and 
financial markets today. 


This document, therefore, revises [RFC7030] to reflect the field reality, deprecating the 
extraneous field. 


This document deals with errata numbers [errata4384], [errata5107], [errata5108], and 
[errata5904]. 


This document deals with [errata5107] and [errata5904] in Section 3. [errata5108] is dealt with in 
Section 5. [errata4384] is closed by correcting the ASN.1 Module in Section 4. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Changes to EST Endpoint Processing 


Sections 4.1.3 (CA Certificates Response, /cacerts), 4.3.1 and 4.3.2 (Full CMC, /fullcmc), 4.4.2 
(Server-Side Key Generation, /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) of [RFC7030] 
specify the use of base64 encoding with a Content-Transfer-Encoding for requests and responses. 
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This document updates [RFC7030] to require the POST request and payload response of all 
endpoints using base64 encoding, as specified in Section 4 of [RFC4648]. In both cases, the 
Distinguished Encoding Rules (DER) [X.690] are used to produce the input for the base64 
encoding routine. This format is to be used regardless of any Content-Transfer-Encoding header, 
and any value in such a header MUST be ignored. 


3.1. White Space Processing 


Note that "base64" as used in the HTTP [RFC2616] does not permit CRLF, while the "base64" used 
in MIME [RFC2045] does. This specification clarifies that despite what [RFC2616] says, white 
space including CR, LF, spaces (ASCII 32), and tabs (ASCII 9) SHOULD be tolerated by receivers. 
Senders are not required to insert any kind of white space. 


3.2. Changes to Section 4 of RFC 7030 


3.2.1. Section 4.1.3 
Replace: 


A successful response MUST be a certs-only CMC Simple PKI Response, as defined in 
[RFC5272], containing the certificates described in the following paragraph. The HTTP 
content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a 
Content-Transfer-Encoding of "base64" [RFC2045]. 


with: 


A successful response MUST be a certs-only CMC Simple PKI Response, as defined in 
[RFC5272], containing the certificates described in the following paragraph. The HTTP 
content-type of "application/pkcs7-mime" is used. The CMC Simple PKI Response is 
encoded in base64 [RFC4648]. 


3.2.2. Section 4.3.1 
Replace: 


If the HTTP POST to /fullcmc is not a valid Full PKI Request, the server MUST reject the 
message. The HTTP content-type used is "application/pkcs7-mime" with an smime-type 
parameter "CMC-request", as specified in [RFC5273]. The body of the message is the 
binary value of the encoding of the PKI Request with a Content-Transfer-Encoding of 
"base64" [RFC2045]. 


with: 
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If the HTTP POST to /fullcmc is not a valid Full PKI Request, the server MUST reject the 
message. The HTTP content-type used is "application/pkcs7-mime" with an smime-type 
parameter "CMC-request", as specified in [RFC5273]. The body of the message is encoded 
in base64 [RFC4648]. 


3.2.3. Section 4.3.2 
Replace: 


The body of the message is the binary value of the encoding of the PKI Response with a 
Content-Transfer-Encoding of "base64" [RFC2045]. 


with: 


The body of the message is the base64 [RFC4648] encoding of the PKI Response. 


3.2.4. Section 4.4.2 
Replace: 


An "application/pkcs8" part consists of the base64-encoded DER-encoded [X.690] 
PrivateKeyInfo with a Content-Transfer-Encoding of "base64" [RFC2045]. 


with: 


An "application/pkcs8" part consists of the base64-encoded, DER-encoded [X.690] 
PrivateKeylInfo. 


Replace: 


In all three additional encryption cases, the EnvelopedData is returned in the response 
as an "application/pkcs7-mime" part with an smime-type parameter of "server- 
generated-key" and a Content- Transfer-Encoding of "base64". 


with: 
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In all three additional encryption cases, the EnvelopedData is returned in the response 
as an "application/pkcs7-mime" part with an smime-type parameter of "server- 
generated-key”". It is base64 encoded [RFC4648]. 


3.2.5. Section 4.5.2 


This section is updated in its entirety in Section 4. 


4. Clarification of ASN.1 for Certificate Attribute Set 
Section 4.5.2 of [RFC7030] is to be replaced with the following text: 


4.5.2 CSR Attributes Response 


If locally configured policy for an authenticated EST client indicates a CSR Attributes 
Response is to be provided, the server response MUST include an HTTP 200 response 
code. An HTTP response code of 204 or 404 indicates that a CSR Attributes Response is 
not available. Regardless of the response code, the EST server and CA MAY reject any 
subsequent enrollment requests for any reason, e.g., incomplete CSR attributes in the 
request. 


Responses to attribute request messages MUST be encoded as the content-type of 
"application/csrattrs" and are to be "base64" [RFC4648] encoded. The syntax for 
application/csrattrs body is as follows: 


CsrAttrs ::= SEQUENCE SIZE (@..MAX) OF AttrOrOID 
AttrOrOID ::= CHOICE { 
oid OBJECT IDENTIFIER, 


attribute Attribute {{AttrSet}} } 


AttrSet ATTRIBUTE ::= { ... } 


An EST server includes zero or more OIDs or attributes [RFC2986] that it requests the 
client to use in the certification request. The client MUST ignore any OID or attribute it 
does not recognize. When the server encodes CSR attributes as an empty SEQUENCE, it 
means that the server has no specific additional information it desires in a client 
certification request (this is functionally equivalent to an HTTP response code of 204 or 
404). 


If the CA requires a particular cryptographic algorithm or use of a particular signature 
scheme (e.g., certification of a public key based on a certain elliptic curve or signing 
using a certain hash algorithm), it MUST provide that information in the CSR Attribute 
Response. If an EST server requires the linking of identity and POP information (see 
Section 3.5), it MUST include the challengePassword OID in the CSR Attributes Response. 
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The structure of the CSR Attributes Response SHOULD, to the greatest extent possible, 
reflect the structure of the CSR it is requesting. Requests to use a particular signature 
scheme (e.g., using a particular hash function) are represented as an OID to be reflected 
in the SignatureAlgorithm of the CSR. Requests to use a particular cryptographic 
algorithm (e.g., certification of a public key based on a certain elliptic curve) are 
represented as an attribute, to be reflected as the AlgorithmIdentifier of the 
SubjectPublicKeyInfo, with a type indicating the algorithm and the values indicating the 
particular parameters specific to the algorithm. Requests for descriptive information 
from the client are made by an attribute, to be represented as Attributes of the CSR, with 
a type indicating the [RFC2985] extensionRequest and the values indicating the 
particular attributes desired to be included in the resulting certificate's extensions. 


The sequence is Distinguished Encoding Rules (DER) encoded [X.690] and then base64 
encoded (Section 4 of [RFC4648]). The resulting text forms the application/csrattr body, 
without headers. 


For example, if a CA requests that a client a) submit a certification request containing 
the challengePassword (indicating that linking of identity and POP information is 
requested; see Section 3.5), b) submit an extensionRequest with the Media Access 
Control (MAC) address [RFC2307] of the client, and c) use the secp384r1 elliptic curve to 
sign using the SHA384 hash function, then it takes the following: 


OID: challengePassword (1.2.840.113549.1.9.7) 


Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 
value = macAddress (1.3.6.1.1.1.1.22) 


Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 
value = secp384r1 (1.3.132.0.34) 


OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 


and encodes them into an ASN.1 SEQUENCE to produce: 


30 41 06 89 2a 86 48 86 f7 Od 01 09 B7 30 12 86 O7 2a 86 48 ce 3d 
02 01 31 07 86 O5 2b 81 04 BO 22 30 16 G6 09 2a 86 48 86 f7 Od 01 
09 ðe 31 89 86 07 2b G6 01 01 01 01 16 86 B8 2a 86 48 ce 3d 04 03 
03 


and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 


MEEGCSqGSIb3DQEJBZASBgcqhkjOPQIBMQcGBSUBBAAİMBYGCSqGSIb3DQEJDjEJ 
BgcrBgEBAQEWBggghk jOPQQDAw== 
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5. Clarification of Error Messages for Certificate Enrollment 
Operations 


[errata5108] clarifies what format the error messages are to be in. Previously, a client might be 
confused into believing that an error returned with type text/plain was not intended to be an 
error. 


5.1. Updating Section 4.2.3: Simple Enroll and Re-enroll Response 
Replace: 


If the content-type is not set, the response data MUST be a plaintext human-readable 
error message containing explanatory information describing why the request was 
rejected (for example, indicating that CSR attributes are incomplete). 


with: 


If the content-type is not set, the response data MUST be a plaintext human-readable 
error message containing explanatory information describing why the request was 
rejected (for example, indicating that CSR attributes are incomplete). Servers MAY use 
the "text/plain" content-type [RFC2046] for human-readable errors. 


5.2. Updating Section 4.4.2: Server-Side Key Generation Response 
Replace: 


If the content-type is not set, the response data MUST be a plaintext human-readable 
error message. 


with: 


If the content-type is not set, the response data MUST be a plaintext human-readable 
error message. Servers MAY use the "text/plain" content-type [RFC2046] for human- 
readable errors. 
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6. Privacy Considerations 


This document does not disclose any additional identities that either an active or passive 
observer would see with [RFC7030]. 


7. Security Considerations 


This document clarifies an existing security mechanism. It does not create any new protocol 
mechanisms. 


All security considerations from [RFC7030] also apply to the clarifications described in this 
document. 


8. IANA Considerations 


The ASN.1 module in Appendix A of this document makes use of object identifiers (OIDs). 


IANA has registered an OID for id-mod-est-2019 (1.3.6.1.5.5.7.0.98) in the "SMI Security for PKIX 
Module Identifier" registry for the ASN.1 module. 


The OID for the Asymmetric Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 
defined in [RFC7030]. IANA has updated the Reference column for the Asymmetric Decryption 
Key Identifier attribute to also include a reference to this document. 
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Appendix A. ASN.1 Module 


This annex provides the normative ASN.1 definitions for the structures described in this 
specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683]. 


The ASN.1 modules makes imports from the ASN.1 modules in [RFC5912] and [RFC6268]. 
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There is no ASN.1 Module in [RFC7030]. This module has been created by combining the lines 
that are contained in the document body. 


PKIXEST-2019 
{ iso(1) identified-organization(3) dod(6) 
internet(1) security(5) mechanisms(5) pkix(7) 
id-mod(@) id-mod-est-2019(98) } 


DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 


-- EXPORTS ALL -- 
IMPORTS 


Attribute 
FROM CryptographicMessageSyntax-2018 -- [RFC6268] 
{ iso(1) member-body(2) us(84@) rsadsi(113549) 
pkcs(1) pkcs-9(9) smime(16) modules(@) 
id-mod-cms-2009(58) } 


ATTRIBUTE 
FROM PKIX-CommonTypes-2009 -- [RFC5912] 
{ iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) id-mod(@) 
id-mod-pkixCommon-@2(57) } ; 


-- CSR Attributes 


CsrAttrs ::= SEQUENCE SIZE (@..MAX) OF AttrOrOID 
AttrOrOID ::= CHOICE { 
oid OBJECT IDENTIFIER, 


attribute Attribute {{AttrSet}} } 


AttrSet ATTRIBUTE ::= { ... } 


-- Asymmetric Decrypt Key Identifier Attribute 
aa-asymmDecryptKeyID ATTRIBUTE ::= 
{ TYPE AsymmetricDecryptKeylIdentifier 
IDENTIFIED BY id-aa-asymmDecryptKeyID } 
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) 
member-body(2) us(84@) rsadsi(113549) pkcs(1) pkcs-9(9) 
smime(16) aa(2) 54 } 
AsymmetricDecryptKeyIdentifier ::= OCTET STRING 


END 
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